Computer documents generally have formats which are specific to a particular application program (e.g., Microsoft.RTM. Word, Microsoft.RTM. Excel, etc.) with which they are created. By convention, the documents' file names have a three letter extension which identifies their file format and associated application program. For example, Microsoft.RTM. Excel spreadsheet documents have an ".xls" file name extension. Drawing documents created in Shapeware Corporation's VISIO.RTM. drawing application program have a ".vsd" file name extension.
These often proprietary format documents typically can only be printed correctly by their associated application program. Users therefore usually print documents by interacting directly with the documents associated application. This requires the user to perform several steps, including: identifying, finding and launching the associated application; opening the document in the application; setting print options; and activating the application's print feature. For the user to avoid this tedious sequence of steps, it often is desirable to allow another computer program (e.g., the operating system or a printing utility) to control printing by the documents associated application. Programmatic printing refers to capability of a computer program (typically the operating system shell, but also other computer programs) to cause a document's associated application program to print the document on a printer.
Various forms of programmatic printing have been available in computer operating systems which provide a graphical user interface (GUI), e.g., Microsoft Windows.RTM. 3.x/95/NT, Apple Macintosh, IBM OS/2, and NewWave. In one or more of these operating systems, the user has been able to drag (e.g., using a mouse) an icon representing a document's file from folders of a file system onto an icon representing a printer to cause the associated application to print the document on the printer. The user thus reduces the multiplicity of steps otherwise required to print a document to a single drag and drop of a document icon with the mouse.
The designs of the programmatic printing features in these prior operating systems, however, have had certain deficiencies. In the Microsoft Windows.RTM. operating system for example, the operating system shell (i.e., the program which provides the operating system's graphical user interface) implements programmatic printing using a shell execute command. Shell execute commands are text string commands (e.g., MS-DOS commands) issued to the operating system command interpreter (i.e., the "command.com" program in Microsoft Windows.RTM.). The operating system includes a registry database which maps a document's file name extension to a particular application, and also maps the application to a particular shell execute command for printing the document. For example, the following sample registry entries in Microsoft Windows.RTM. 95 map the file name extension of Microsoft.RTM. Word documents (i.e., ".doc") to a shell execute command: EQU HKEY_CLASSES_ROOT.backslash..doc wordfile EQU . . . EQU HKEY_CLASSES_ROOT.backslash.wordfile.backslash.Shell.backslash.print.backsl ash.Command EQU c:.backslash.winword.backslash.winword6.exe -p %1
Thus, in response to the user dragging a Word document icon onto a printer icon in the Windows graphical user interface, the Windows shell maps the document's ".doc" file name extension to the text string "c:.backslash.winword.backslash.winword6.exe -p %1" from the above sample registry entries. The shell then substitutes the document's file name for the "%1" argument of the text string, and issues the string as a shell execute command to the Windows command interpreter. This command directs the command interpreter to load the Microsoft.RTM. Word executable program, and to pass the print flag ("-p") and the document's file name to the program as command line arguments. These command line arguments direct the Word program to print the document when the program begins executing.
A drawback to programmatic printing with the shell execute command is that it is essentially a one-way, "throw over the fence" mechanism. That is to say, once the Windows.RTM. shell or other controlling program initiates printing with a shell execute command, it has no further control of the application program which performs the print operation and it receives no information back from the application on the progress, success or failure of the print operation. Thus, the controlling program cannot report the status of the print operation to the user, and cannot suspend, cancel, or otherwise affect or control the print operation once initiated. When launched from a shell execute command, the associated application generally does not provide a user interface for controlling the print job. (Applications launched with a print flag as a command line argument generally are expected to print the specified document without user interaction.) Thus, the print job typically can only be canceled by the printer's driver program (e.g., through a separate print manager utility program which interacts with the printer's driver), or by physically turning the printer off.
Since there is a lack of sufficient feedback from the application when the print operation completes, the controlling program also cannot terminate the application after the print operation is complete, but instead must rely on the application program to terminate at print operation completion. The programmatic printing feature of the Windows.RTM. operating system assumes that application programs which are launched with a print flag as a command line argument will terminate after the print operation completes. However, only about half of the application programs which accept a print flag as a command line argument actually are designed to terminate when the print operation completes. Those applications which are not designed to terminate at print operation completion continue consuming computer resources (i.e., memory, processing cycles, etc.), although no longer in use, until terminated manually by the user.
The prior programmatic printing feature using the shell execute command also has the flaw that the shell has no control over the associated application displaying its user interface. Once the shell execute command is issued, the associated application takes over and can display graphic elements, such as a starting graphic while loading, the application's print options dialog, or a complete application window. The Windows.RTM. shell assumes that applications which are loaded with the print flag as a command line argument do not display graphic elements. Many applications, however, violate this assumption. The graphic elements they display can obscure other work the user is performing with the shell, and are generally unexpected by the user. When the user drags a document icon onto a printer icon, the user often understands only that they are working in the Windows.RTM. shell program and may not realize that the actual print operation activated by the drag and drop action is being carried out behind the scenes by the document's associated application. The display of graphic elements by the associated application destroys this illusion, and typically is not the expected result of the user's drag and drop action. The graphic elements also may obstruct the user from performing other work in the shell.
Another drawback to the shell execute programmatic printing feature is that the Windows.RTM. shell has extremely limited control over the actual print operation. In fact, the only direct control that the shell has over the print operation is which document is printed by its associated application. The mapping from file name extension to shell execute command allows the shell to specify only the file name of the target document to the application. The mapping to a shell execute command does not allow the shell to specify any other aspects of the print operation to the application. Thus, the shell is unable to set any print options, such as the paper orientation (e.g., landscape or portrait orientations), the printer paper tray, any document specific options (e.g., which pages), or even which printer is used.
The Windows.RTM. shell works around the latter limitation (of not being able to specify which printer to use through the shell execute command) indirectly by temporarily changing the operating system's default printer setting. The shell's programmatic printing feature assumes that the application programs which are launched with a print flag as a command line argument perform the print operation on the default printer set by the operating system. Thus, by changing the default printer setting before issuing the shell execute command, the shell can cause the associated application launched with the shell execute command to print to any desired printer. However, although the assumption that the application prints to the default printer is generally true, temporarily changing the default printer setting can have undesirable or even disastrous results.
First, since there is no direct feedback from the associated application, the Windows.RTM. shell cannot reliably determine when the associated application completes printing the document so as to restore the original default printer setting. The shell can monitor the activity of the printer drivers in an attempt to indirectly determine when the document has completed printing. However, due to the possibility of the printer having other print jobs pending, this indirect determination is sometimes inaccurate.
Second, Microsoft Windows.RTM. is a multi-tasking operating system, which means that multiple programs can execute concurrently on the system. When the Windows.RTM. shell changes the default printer setting, the default printer is changed for all applications. Many applications, however, contemporaneously format documents that they have open according to the current default printer setting. Thus, temporarily changing the default printer setting by the shell's programmatic printing feature may cause these applications to immediately reformat their open documents according to the new default printer setting, and again reformat their open documents when the shell restores the original default printer setting, thereby providing unpredictable behaviour and wasting resources.
Third, changing the default printer setting can cause print jobs to be unexpectedly redirected to another printer. Applications typically present a user interface dialog with controls that show and allow the user to select various print options, including the destination printer. An unfortunate timing sequence can occur where the shell's programmatic printing feature changes the default printer setting after the user has selected the default printer as the destination of a separate print job in some application's print options dialog and before the user initiates that print job. In this case, the user expects the print job to go to the original default printer shown in the print options dialog, but instead the print job is redirected with the programmatic printing feature's print job to the new temporary default printer. On a local area network having many printers in diverse locations such as is common in many large businesses, it can be very confusing for the user to determine where the print job was printed (and why).
Further, changing the default printer setting by the shell's programmatic printing feature while another print job is being printed to the default printer may also cause the operating system to "crash" (i.e., to become inoperative). This situation can occur where the user drags a first document's icon onto a first printer's icon, and then drags a second document's icon onto a second printer's icon while the first document's application begins printing to the default printer. The shell's programmatic printing feature, by changing the default printer setting to the second printer in the middle of the first document's print operation, may cause the operating system to crash.
Prior programmatic print previewing features also have had many flaws. Print previewing refers to a feature which produces a display or internal data representation of the document as it would appear when printed. This allows the user to view the document for errors before printing. Print previewing also can produce a small graphic image of the document (referred to as a "thumbnail") which is useful for document management, e.g., to allow the user to select documents from a collection based on its appearance from a set of thumbnails of the documents in the collection, rather than a file name or other identification.
A typical prior programmatic print preview feature uses the previous programmatic printing with the shell execute command, and further substitutes a custom printer driver for the default printer. The custom printer driver feeds page images directly to the client in a private data format conducive to the client's needs. The approach has the drawback that the custom printer driver generally is modeled on a generic printer, and does not necessarily reflect how the document will appear on a specific printer. Since a document's appearance can vary significantly between printers, this approach often does not accurately preview the document as it will appear on a specific printer. Thus, the print preview obtained from this approach may appear without errors, while the document may not have the desired appearance when printed on the specific printer.
Microsoft Corporation's Object Linking and Embedding (OLE) component software technology provides many useful techniques which allow different computer programs to work together. In conformance with OLE specifications, data such as for a computer document is combined with associated program code that operates on the data to form an entity referred to as an object. Objects in OLE include interfaces through which other programs can interact with the object. The interfaces have member functions (also referred to as methods on the interface) that the programs can invoke directly as a function call. OLE defines many different interfaces which allow application programs to provide features such as embedding and linking of non-native data formats into compound documents (e.g., inserting a Microsoft.RTM. Excel spreadsheet and a VISIO.RTM. drawing into a Microsoft.RTM. Word document); in-place activation and editing of embedded or linked data in the compound document; inter-application copy, cut and paste operations; inter-application drag and drop operations; and others. OLE, however, has not previously provided support specifically for programmatic document printing.
The present invention provides an object interface structure for programmatic document printing which overcomes the above described flaws of previous programmatic document printing feature designs. The object interface structure defines a print interface to objects (hereafter "document objects") which encapsulate document data and program code (i.e., a set of functions) for operating on the data. A client application program (e.g., an operating system shell or other program which provides a programmatic document printing feature) interacts with the document object through the print interface and can cause the object to print its document data by performing a function call to a print member function on the interface.
According to a first aspect of the invention, the object interface structure may provide continuing interaction between the client application and the document object. In the illustrated object interface structure, the client application includes a call back interface. At the time the client application makes its call to the print function on the document object's print interface, the client application passes a call back interface pointer to the document object. The document object can then interact with the client application by calling member functions on the call back interface of the client application. The document object calls functions on the client's call back interface to notify the client application of the status of the print operation, including the progress, success or failure of the print operation. Thus, the client can, if desired, display graphical user interface elements indicating the print operation status, such as a "% complete" progress indicator, and success or failure notification dialogs. The client also can participate in the print operation by returning values from the document object's calls to the call back interface that cause the document object to cancel, resume, suspend, or otherwise modify, or monitor the print operation.
According to another aspect of the invention, the object interface structure provides the client with control over aspects of the print operation beyond the determination of which document is printed. In the illustrated object interface structure, the document object's print interface also has member functions which the client calls to query information about the document's page numbers and to set the range of page numbers to be printed. The client passes flags as an argument in calls to the print member function to control aspects of the print operation, such as display of graphical user interface elements by the document object or printing to a particular printer or file. The print member function also accepts a data structure as an argument which contains document specific print options. This data structure has an extensible format to allow inclusion of any number and types of values to control print options specific to a particular document.
In accordance with further aspects of the invention, the object interface structure supports various programmatic printing methodologies not possible with the shell execute command and like previous programmatic printing features. As an example, with the illustrated print interface, the client application can opaquely convey document specific print options to document objects. Specifically, the client can make a first call to the print interface of a first document object to cause that document object to display its print options dialog and gather a set of print option settings from the user. The client can then pass the same set of print options settings gathered from the call to the first document object in calls to the print interfaces of other like document objects so as to programmatically print their documents using the same print option settings, but without repeatedly prompting the user to set the print options of those documents. The client simply passes the print option settings data structure (as essentially a "bit bucket") in its calls to the print interface of each document object, and need not manipulate the print option settings itself. Thus, the client can convey print option settings between document objects with a complex group of print options (e.g., for a high-end computer aided design program) and document objects with simple print options (e.g., for a basic word processor) alike, using the same interface design and without having to include logic in its code specific to a particular document's print options.
As a further example, the client application can print a group of separate documents with consecutive page numbering from document to document. The print interface includes a member function for setting the initial page number of the document. The client application calls this function to set the initial page number of each document in the group to have consecutive page numbers from document to document.
According to yet another aspect of the invention, the object interface structure also defines a print preview interface to document objects which supports gathering print previews of documents. Client applications can interact with a document object's print preview interface to gather data for displaying a preview of the appearance of a document when printed on a particular printer. This print preview feature is useful to allow the user to verify that a document will have a desired format and appearance when actually printed on the printer, and also can be used for document management applications (e.g., to display a "thumbnail" graphic of the document).